[LLVM->SPIRV] Cast the GEP base pointer to source type upon mismatch by karolzwolak · Pull Request #3255 · KhronosGroup/SPIRV-LLVM-Translator

karolzwolak · 2025-07-08T07:27:53Z

The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]).
This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed.

This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain.
This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior.

For example:
Before this change, the following GEP was translated incorrectly:
getelementptr(i8, ptr addrspace(1) @a_var, i64 2)
Whereas this nearly equivalent GEP was handled correctly:
getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1)

Previously, the first form was incorrectly interpreted as:
getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2)

The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., `ptr i8` vs. `ptr [N x T]`). This mismatch can lead to incorrect address computations during translation to SPIR-V, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an `PtrAccessChain`. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: `getelementptr(i8, ptr addrspace(1) @a_var, i64 2)` Whereas this nearly equivalent GEP was handled correctly: `getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1)` Previously, the first form was incorrectly interpreted as: `getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2)`

karolzwolak · 2025-07-08T08:23:32Z

@MrSidims Could you please take a look at this?
PS: I made this for previous LLVM versions, and I'm not sure what should be done on the SPIR-V untyped pointers.
Should we just skip the bitcast or is this fine?

MrSidims

@karolzwolak if you don't mind, I have changed the description from
This mismatch can lead to incorrect address computations during translation to SPIR-V
to
This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context

MrSidims · 2025-07-08T13:49:09Z

what should be done on the SPIR-V untyped pointers

If you are asking about SPV_KHR_untyped_pointers - I believe we can skip this corner case for now.

karolzwolak · 2025-07-08T13:49:54Z

Great, I don't mind the description change.

…e upon mismatch (KhronosGroup#3255) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2)

…er to source type upon mismatch (KhronosGroup#3255) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2)

…er to source type upon mismatch (#3255) (#3263) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2)

…e upon mismatch (KhronosGroup#3255) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2) (cherry picked from commit 1be9366)

wenju-he · 2026-03-03T06:56:53Z

/backport llvm_release_200

github-actions · 2026-03-03T06:57:07Z

Attempting to create backport to llvm_release_200...

…3255) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2)

github-actions · 2026-03-03T06:57:12Z

Success. Backport PR created: #3614

wenju-he · 2026-03-03T07:01:25Z

/backport llvm_release_190

github-actions · 2026-03-03T07:01:37Z

Attempting to create backport to llvm_release_190...

github-actions · 2026-03-03T07:01:38Z

Backport to llvm_release_190 failed due to conflicts on commit 1be936678fd8bbeb224470eedbd19d78a833beb7. Please backport manually.

…hronosGroup#3255) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2) (cherry picked from commit 1be9366)

…e upon mismatch (#3255) (#3612) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2) (cherry picked from commit 1be9366) Co-authored-by: Karol Zwolak <karolzwolak7@gmail.com>

…hronosGroup#3255) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2) (cherry picked from commit 1be9366)

…r to source type upon mismatch (#3614) Backport of PR #3255 into `llvm_release_200`. All commits applied cleanly. Co-authored-by: Karol Zwolak <karolzwolak7@gmail.com>

…e upon mismatch (#3255) (#3615) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2) (cherry picked from commit 1be9366) Co-authored-by: Karol Zwolak <karolzwolak7@gmail.com>

…e upon mismatch (#3255) (#3642) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2) (cherry picked from commit 1be9366) Co-authored-by: Karol Zwolak <karolzwolak7@gmail.com>

…e upon mismatch (KhronosGroup#3255) (KhronosGroup#3612) The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]). This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed. This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain. This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior. For example: Before this change, the following GEP was translated incorrectly: getelementptr(i8, ptr addrspace(1) @a_var, i64 2) Whereas this nearly equivalent GEP was handled correctly: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1) Previously, the first form was incorrectly interpreted as: getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2) (cherry picked from commit 1be9366) Co-authored-by: Karol Zwolak <karolzwolak7@gmail.com>

karolzwolak force-pushed the gep-cast-operand-to-source branch from 88233ee to 8c5a9d9 Compare July 8, 2025 07:29

format

1252e4c

also test spirv->llvm translation

c38c46b

karolzwolak force-pushed the gep-cast-operand-to-source branch from dfb2031 to c38c46b Compare July 8, 2025 11:10

MrSidims approved these changes Jul 8, 2025

View reviewed changes

MrSidims merged commit 1be9366 into KhronosGroup:main Jul 9, 2025
9 checks passed

svenvh mentioned this pull request Aug 18, 2025

Indicies in SpecConstantOp PtrAccessChain of global variales are not adjusted for their actual type. #2468

Closed

wenju-he mentioned this pull request Mar 3, 2026

[Backport to 17][LLVM->SPIRV] Cast the GEP base pointer to source typ… #3612

Merged

github-actions bot mentioned this pull request Mar 3, 2026

[Backport to llvm_release_200] [LLVM->SPIRV] Cast the GEP base pointer to source type upon mismatch #3614

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[LLVM->SPIRV] Cast the GEP base pointer to source type upon mismatch#3255

[LLVM->SPIRV] Cast the GEP base pointer to source type upon mismatch#3255
MrSidims merged 3 commits intoKhronosGroup:mainfrom
karolzwolak:gep-cast-operand-to-source

karolzwolak commented Jul 8, 2025 •

edited by MrSidims

Loading

Uh oh!

karolzwolak commented Jul 8, 2025

Uh oh!

MrSidims left a comment •

edited

Loading

Uh oh!

MrSidims commented Jul 8, 2025

Uh oh!

karolzwolak commented Jul 8, 2025

Uh oh!

Uh oh!

wenju-he commented Mar 3, 2026

Uh oh!

github-actions bot commented Mar 3, 2026

Uh oh!

github-actions bot commented Mar 3, 2026

Uh oh!

wenju-he commented Mar 3, 2026

Uh oh!

github-actions bot commented Mar 3, 2026

Uh oh!

github-actions bot commented Mar 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

karolzwolak commented Jul 8, 2025 • edited by MrSidims Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

karolzwolak commented Jul 8, 2025

Uh oh!

MrSidims left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MrSidims commented Jul 8, 2025

Uh oh!

karolzwolak commented Jul 8, 2025

Uh oh!

Uh oh!

wenju-he commented Mar 3, 2026

Uh oh!

github-actions bot commented Mar 3, 2026

Uh oh!

github-actions bot commented Mar 3, 2026

Uh oh!

wenju-he commented Mar 3, 2026

Uh oh!

github-actions bot commented Mar 3, 2026

Uh oh!

github-actions bot commented Mar 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

karolzwolak commented Jul 8, 2025 •

edited by MrSidims

Loading

MrSidims left a comment •

edited

Loading